Having a scalable, robust replication system for business data is critical to business operation, and thus, business data are often replicated to other systems located at different geographic sites. Replicating data to other systems across different sites is often called a multisite based replication technique and is used to improve operational continuity in doing business because the multisite based replication technique provides increased availability of data for business and improves operational performance by balancing network loading among multiple database systems.
Data accuracy, data availability, and conflict resolution are considerations for the implementation of data replication systems and maintenance of such systems. Data accuracy relates to accuracy of data being replicated and is sometimes referred to as data integrity. Data availability is availability of data for use even in case of a system failure or system unavailability. Conflict resolution is a procedure used when two transactions originating from different systems occur for the same record at nearly the same time.
Currently, there are a number of existing techniques for replicating data across multiple systems located at different sites. One example is hardware based replication. Hardware based replication replicates all changes from one system (or a primary system) to another (or a secondary system) in a synchronous manner at a hardware disk level such that every change made on the primary system is simultaneously made on the secondary system. Data of the secondary system is not made accessible until it is needed. But, when users are switched to the secondary system, the secondary system contains all the changes that were made to the primary system. One complication with hardware based replication is that since data is simultaneously replicated at a hardware disk level, operating systems and database versions running on each system generally must have exact matches. Thus, hardware based replication is generally more expensive than a software based solution because this exact matching of hardware and/or software between the primary and secondary systems must be maintained.
There are software based techniques for replicating data. Some software based techniques replicate data synchronously, allowing changes to a primary system only after the same changes have been made to a secondary system. This technique, however, tends to reduce application performance because of the increased amount of communication between the primary and secondary systems, and causes possible delays on the secondary system, before allowing a transaction to complete.
Other software based techniques replicate data asynchronously, providing various levels of completeness, accuracy, performance, latency and flexibility in replicating the data. One example is a master-to-slave replication technique, in which one system acts as a primary (or master) system and the other systems perform as secondary (or slave) systems. The slave systems always follow the master system. Write operations are only performed on the master system, but read operations can be performed on the master and slave systems alike. In some cases, any of the systems can serve as the master system, but at any given time only one master system exists.
In the master-to-slave replication technique, all inserts, deletes, and updates are submitted only to the master system, and are then replicated to other slave systems. In addition, all write operations (or transactions) are made directly to a main table of data of the master system and subsequently replicated to main tables of data of the slave systems. Thus, by having only a single system (e.g., a master system) that accepts write transactions, there is no issue with data accuracy and conflict resolution. However, implementing master-to-slave replication requires a complex implementation architecture, and switching operation of a system from serving as a master system to serving as a slave system (and vice versa) can create many complex challenges. Further, limiting write transactions to a single master system often introduces significant capacity and latency issues for high volume and/or a geographically distributed configuration of systems.
Because of the architectural complexity and implementation challenges encountered in the master-to-slave replication, a technique known as peer-to-peer replication is often preferred for a multisite based replication system. Peer-to-peer replication allows users to make changes concurrently to the same table across multiple active systems because all of the systems act as peers. Peer-to-peer replication allows any local change on a system to be replicated to all of the other systems, keeping all databases in synchronization with each other. In other words, if a record in a main table of a first system is changed, then the change or transaction is replicated to the main tables of the other systems. For example, when inserting a new record on a system A, an insert transaction is generated and replicated directly on the main tables of the other systems (e.g., systems B, C, etc). For deleting a record on the system A, a delete transaction is generated and replicated directly to the main tables of the other systems. Similarly, for updating a record on the system A, an update transaction is generated and replicated directly to the main tables of the other systems. However, replicating data directly to the main tables of the other systems tends to create conflicts and reduce data integrity.
Common types of conflicts encountered in peer-to-peer replication are: insertion conflicts, update conflicts, and delete conflicts. An insertion conflict occurs when two or more systems simultaneously attempt to insert records with the same key in the same table. An update conflict occurs when simultaneous updates by two or more systems are performed on the same record. A deletion conflict occurs when one system deletes a record that another system updates before the delete transaction is implemented.
With existing peer-to-peer replication techniques, accuracy of data is not guaranteed in view of such conflicts. Further, with the existing peer-to-peer replication techniques, a transaction can loop across multiple systems since there is no mechanism to stop the transaction at the originating system. Coping with these inherent shortcomings with the existing peer-to-peer replication techniques often requires major compromises in database design, which might not be practical when prepackaged third party applications are used. Furthermore, the existing peer-to-peer replication techniques require often complex routines for resolving the conflicts and for prioritizing which replicated transactions are accepted for posting to target systems when two or more users change the same record at or near the same time.